\documentclass[12pt]{article}
\usepackage{floatrow}
\usepackage{caption}
\usepackage{graphicx}
\usepackage{indentfirst}
\usepackage[T1]{fontenc}
\pagestyle{empty}
\setcounter{secnumdepth}{2}

\topmargin=0cm
\oddsidemargin=0cm
\textheight=22.0cm
\textwidth=16cm
\parindent=5mm
\parskip=0.15cm
\topskip=0truecm
\raggedbottom
\abovedisplayskip=3mm
\belowdisplayskip=3mm
\abovedisplayshortskip=0mm
\belowdisplayshortskip=2mm
\normalbaselineskip=12pt
\normalbaselines

\begin{document}

\vspace*{0.5in}
\centerline{\bf\Large Design Document}

\vspace*{0.5in}
\centerline{\bf\Large Team 4}

\vspace*{0.5in}
\centerline{\bf\Large 11 March 2012}

\vspace*{1.5in}
\begin{table}[htbp]
\begin{center}
\begin{tabular}{|r | c|}
\hline
Name & ID Number \\
\hline\hline
Alex Attar & 9609695 \\
Kevin Carrington & 9470034 \\
Kevin El Hage & 9765727 \\
Jaime Francisco Jaramillo & 9272518 \\
Jimmy Nguyen & 5493277 \\
Scott Renaud & 9354891 \\
\hline
\end{tabular}
\end{center}
\end{table}

\clearpage

\pagestyle{plain}
\setcounter{page}{1}
\pagenumbering{arabic}

\section{Introduction}

This document presents a detailed design for the implementation of a Task Management System, as described in the User Requirements Document. The document contains UML diagrams to illustrate the proposed architecture design (division into subsystems), the individual subsystem's internal class structure, and some execution scenarios for the whole system. Additionally, this document presents a detailed description of the interfaces that can be used for communication between the subsystems.

\subsection{Revision History}

Removal of the role selection part of the system (as described in the User Requirements Document): Since we are using our team as the client of our system and we do not have clearly defined "hierarchical" roles (e.g. team leader), we decided to leave out the role selection feature. The feature would not be adding any critical functionality and could be removed without affecting the rest of the system.

\newpage

\section{Architectural Design} \label{sec:arch}

This section describes the architectural design of the Task Management System. It includes a diagram illustrating the high-level division into subsystems and explains the rationale behind this design. Additionally, this section contains a description of the function calls each of the subsystems can use to communicate with each other.

\subsection{Architectural Diagram}

\begin{figure}[htbp]
\includegraphics[scale=0.75]{architectureDesignComplete}
\end{figure}

The architectural design of the Task Management System follows the MVC architectural pattern. The system is divided into 3 subsystems, each one reflecting the responsibilities of one part of MVC. The Model Subsystem represents the data and the business logic. The Model takes care of permanent storage of the data (XML file), the volatile representation of the data (run-time data structures), and any modification to said data.  The Controller Subsystem is responsible for handling user input in the form of events handlers. It registers the different views and notifies them of any changes that must be made in presentation. The Controller is also responsible for updating the Model, in order to reflect user interaction with the system. The View Subsystem takes care of the visual presentation (UI) of the system. It is responsible for sending user input (events) to the controller and visually representing the current state of the data (Model). \\

This architecture design was chosen to achieve a greater separation of concerns by having each subsystem responsible for a specific part of the overall system. The implementation of the system is expected to respect this separation by grouping each subsystem into packages. Furthermore, the Default package does not represent a subsystem in itself; it should contain the entry point to whole system (i.e. the "main" function), which loads the initial configuration from the model.

\subsection{Subsystem Interface Specifications}

Each one of the subsystems has its own set of functions that can be used by other parts of the system to fulfill a certain service. The following is a division of the interface specifications according to each subsystem.

\subsubsection{2.2.1 Model Subsystem Interface}

The Model Subsystem uses the \usefont{T1}{pcr}{m}{sl} Model\usefont{T1}{tnr}{m}{n} module (class) as an entry point for interaction with other subsystems. An instance of the \usefont{T1}{pcr}{m}{sl} Model\usefont{T1}{tnr}{m}{n} class offers the following functions to have a service fulfilled:

\begin{itemize}
\item\usefont{T1}{pcr}{m}{sl} clearData() \\
\usefont{T1}{tnr}{m}{n} Cleans up the volatile representation of the data (data structures)
\item \usefont{T1}{pcr}{m}{sl} getTasks():Vector<Task> \\
\usefont{T1}{tnr}{m}{n} Returns a vector of all the tasks loaded from permanent storage
\item \usefont{T1}{pcr}{m}{sl}  getPeople():Vector<Person> \\
\usefont{T1}{tnr}{m}{n} Returns a vector of all the people with assigned tasks
\item \usefont{T1}{pcr}{m}{sl} addTask() \\
\usefont{T1}{tnr}{m}{n} Creates a new, empty Task and generates a unique ID (not returned) for it.
\item \usefont{T1}{pcr}{m}{sl}  removeTask(taskID:int) \\
\usefont{T1}{tnr}{m}{n} Removes the Task with the given ID from volatile storage.
\usefont{T1}{tnr}{m}{n} The range for the parameter is from 0 to the number of existing tasks minus 1.
\item \usefont{T1}{pcr}{m}{sl}  updateTask(taskID:int, column:int, newValue:Object) \\
\usefont{T1}{tnr}{m}{n} Updates a task in the current state of the model.
The range for \usefont{T1}{pcr}{m}{sl} taskID \usefont{T1}{tnr}{m}{n} is from 0 to the number of existing tasks minus 1.
The range for column is from 0 to 6.
newValue can be a String or an integer.
\item \usefont{T1}{pcr}{m}{sl}  loadTasks(filename:String) \\
\usefont{T1}{tnr}{m}{n} Loads all the tasks from the given file (permanent storage) into data structures.
filename needs to be a valid name of a task XML file.
\item \usefont{T1}{pcr}{m}{sl} saveData(filename:String) \\
\usefont{T1}{tnr}{m}{n} Saves the current state of the Model into permanent storage (file).
 \usefont{T1}{pcr}{m}{sl}filename \usefont{T1}{tnr}{m}{sl} needs to be a valid name of a task XML file.
\item \usefont{T1}{pcr}{m}{sl}  buildPeopleFromTasks() \\
\usefont{T1}{tnr}{m}{n} Triggers the creation of data structures representing the people associated with all the currently loaded Tasks.
\item \usefont{T1}{pcr}{m}{sl} hasChanged():boolean \\
\usefont{T1}{tnr}{m}{n} Returns true if there has been a change in the Model state---difference with permanent storage.
\end{itemize}

\subsubsection{2.2.2 Controller Subsystem Interface}

The Controller Subsystem uses the \usefont{T1}{pcr}{m}{sl} Listener\usefont{T1}{tnr}{m}{n}, \usefont{T1}{pcr}{m}{sl} TaskTableListener \usefont{T1}{tnr}{m}{n} modules (classes) as entry points for interaction with other subsystems. 

An instance of the \usefont{T1}{pcr}{m}{sl} Listener \usefont{T1}{tnr}{m}{n} class offers the following function for communication:

\begin{itemize}
\item \usefont{T1}{pcr}{m}{sl} actionPerformed(e:ActionEvent) \\
\usefont{T1}{tnr}{m}{n}Allows another subsystem (the View) to pass an event to the Controller subsystem.
The Controller Subsystem will automatically react according to the type of event presented.
Any \usefont{T1}{pcr}{m}{sl} ActionEvent \usefont{T1}{tnr}{m}{n} can be passed to this function. If the system does not have a proper response for a specific event, it is ignored.
\end{itemize}

An instance of the \usefont{T1}{pcr}{m}{sl} TaskTableListener \usefont{T1}{tnr}{m}{n} class offers the following function for 
communication:

\begin{itemize}
\item \usefont{T1}{pcr}{m}{sl} TableChanged(evt:TableModelEvent) \\
\usefont{T1}{tnr}{m}{n} Allows another subsystem (the View) to communicate that a change has been made to a table representation of the data.
The event has to be a valid \usefont{T1}{pcr}{m}{sl} TableModelEvent\usefont{T1}{tnr}{m}{n}.
\end{itemize}

\subsubsection{2.2.3 View Subsystem Interface}

The View Subsystem uses the View module (class) as an entry point for interaction with other subsystems. An instance of the View class offers the following functions to have a service fulfilled:

\begin{itemize}
\item \usefont{T1}{pcr}{m}{sl} addActionListeners(l:ActionListener) \\
\usefont{T1}{tnr}{m}{n} Allows the registration of event listeners  (normally from the controller).
Any event listener that implements the Java \usefont{T1}{pcr}{m}{sl} ActionListener \usefont{T1}{tnr}{m}{n} interface can be passed to this function.
\item \usefont{T1}{pcr}{m}{sl} addTaskTableListener(l:TableModelListener) \\
\usefont{T1}{tnr}{m}{n} Allows the registration of  \usefont{T1}{pcr}{m}{sl}TableModelListener. \usefont{T1}{tnr}{m}{n}  Since tables have a very specific behavior, this function is required to register an event listener of the type \usefont{T1}{pcr}{m}{sl}TableModelListener\usefont{T1}{tnr}{m}{n}.
\item \usefont{T1}{pcr}{m}{sl} emptyTaskTable() \\
\usefont{T1}{tnr}{m}{n} Cleans up the Task table (i.e. Task view). 
\item \usefont{T1}{pcr}{m}{sl} emptyPersonTable() \\
\usefont{T1}{tnr}{m}{n} Cleans up the Person table (i.e Person view). 
\item \usefont{T1}{pcr}{m}{sl}getSelectedTaskID():int \\
\usefont{T1}{tnr}{m}{n} Allows for the retrieval of the ID of the currently (user) selected Task in the Task Table (view).
Returns an integer representing the ID. The range is the number of Tasks loaded minus 1. 
\item \usefont{T1}{pcr}{m}{sl} getSelectedRow():int \\
\usefont{T1}{tnr}{m}{n} Allows for the retrieval of the ID of the currently (user) selected Task.
Returns an integer representing the ID. The range is the number of Tasks loaded minus 1. 
\item \usefont{T1}{pcr}{m}{sl} populateTaskTable() \\
\usefont{T1}{tnr}{m}{n} Allows another subsystem to notify the View Subsystem that the Task Table (view) needs to be updated (from the current Model state).
\item  \usefont{T1}{pcr}{m}{sl}populatePersonTable() \\
\usefont{T1}{tnr}{m}{n} Allows another subsystem to notify the View Subsystem that the Person Table (view) needs to be updated (from the current Model state).
\item  \usefont{T1}{pcr}{m}{sl} populateGanttView() \\
\usefont{T1}{tnr}{m}{n} Allows another subsystem to notify the View Subsystem that the Gantt View needs to be updated (from the current Model state).
\item  \usefont{T1}{pcr}{m}{sl} populateTreeView() \\
\usefont{T1}{tnr}{m}{n} Allows another subsystem to notify the View Subsystem that the Tree View needs to be updated (from the current Model state).
\end{itemize}

\newpage

\section{Detailed Design} \label{sec:detail}

This section describes the internal structure of each subsystem in detail. 

\subsection{Model Subsystem}

\subsubsection{Detailed Design Diagram of the Model Subsystem}

\begin{figure}[htb]
\includegraphics[scale=0.6]{Model-subsystem}
\end{figure}

The Model Subsystem is in charge of the data. The subsystem contains the \usefont{T1}{pcr}{m}{sl} Model \usefont{T1}{tnr}{m}{n} class, which serves the purpose of interface to interact with other subsystems. This design separates the different services and data structures that represent the permanent and volatile states of the data and the services associated with it (e.g. input and output from/to XML files). 

\subsubsection{Units Description}

\begin{itemize}
\item \usefont{T1}{pcr}{m}{sl} Model \\
\usefont{T1}{tnr}{m}{n} This class serves as the entry point to the subsystem. The implementation of this class must provide a clear, simple interface for communication with other subsystems. This class centralizes the functionality and services provided by the subsystem, containing instances of the other modules. 
\item \usefont{T1}{pcr}{m}{sl} Person \\
\usefont{T1}{tnr}{m}{n} This class represents all the properties and functions of a Person in the system. An instance of this class maintains the current state of a Person in the system (e.g. list of tasks currently associated with a person).
\item \usefont{T1}{pcr}{m}{sl} IOHandler \\
\usefont{T1}{tnr}{m}{n} This class is responsible for permanent storage of the data's state. It provides functions to read and write from/to XML files.
\item \usefont{T1}{pcr}{m}{sl} Task \\
\usefont{T1}{tnr}{m}{n} This class represents all the properties and functions of a Task in the system. An instance of this class maintains the current state of a Task in the system (e.g. its unique ID, the person associated with the task).
\end{itemize}

\newpage

\subsection{Controller Subsystem}

\subsubsection{Detailed Design Diagram of the Controller Subsystem}

\begin{figure}[htb]
\includegraphics[scale=0.6]{Controller-subsystem}
\end{figure}

The Controller Subsystem is in charge of taking user input (in the form of events) and performing actions accordingly (i.e changing the state of the Model, notifying the Views of changes). This design separates the registration of the event listeners (\usefont{T1}{pcr}{m}{sl} Controller \usefont{T1}{tnr}{m}{n} class) and the event listeners themselves, which are to be implemented as separate classes to maintain modularity. 

\subsubsection{Units Description}

\begin{itemize}
\item \usefont{T1}{pcr}{m}{sl} Controller \\
\usefont{T1}{tnr}{m}{n} The \usefont{T1}{pcr}{m}{sl} Controller \usefont{T1}{tnr}{m}{n} class is responsible for keeping track of the application's subsystems. An instance of this class registers/maps the appropriate event handlers to View elements. \usefont{T1}{pcr}{m}{sl} Controller \usefont{T1}{tnr}{m}{n} also activates/displays the View (User Interface) after the initial configuration is loaded.
\item \usefont{T1}{pcr}{m}{sl} Listener \\
\usefont{T1}{tnr}{m}{n} The Listener unit takes care of all event listeners of type \usefont{T1}{pcr}{m}{sl}ActionEvent\usefont{T1}{tnr}{m}{n}. Since they can be associated with different user actions, this class decides which action to perform and make changes to model and views accordingly (e.g. the creation of a new file triggers the clean up of the current state in the model, as well as the presentation of the Task, Person, Tree and Gantt views).
\item \usefont{T1}{pcr}{m}{sl} TaskTableListener \\
\usefont{T1}{tnr}{m}{n} Given that the Task table (view) is editable by the user, it was decided that a separate listener would help maintain code readability and modularity. This class takes care of this particular behavior of the presentation of Tasks. It listens for changes in the Task table and triggers the corresponding updates in the model and other views.
\item \usefont{T1}{pcr}{m}{sl} TreeClickListener \\
\usefont{T1}{tnr}{m}{n} The tree view also has offers a limited level of interactivity for the user. Therefore, we decided to have a dedicated listener for it. When the user clicks on a particular task, this class decides how it is represented (expand/collapse tree).
\item \usefont{T1}{pcr}{m}{sl} WindowSaveOnExitListener \\
\usefont{T1}{tnr}{m}{n} This is a dedicated listener that decides what to do when the exits the application (i.e. prompt for confirmation or file save option).
\end{itemize}

\newpage

\subsection{View Subsystem}

\subsubsection{Detailed Design Diagram of the Vew Subsystem}

\begin{figure}[htb]
\includegraphics[scale=0.52]{View-subsystem}
\end{figure}

As stated in the architectural design section, the View Subsytem contains the elements and functions of the visual representation of the system (i.e. the User Interface). This design separates the entry point of the subsystem (the View class) from the different views available to the user. In this manner it is possible to keep each visual representation of the data separate, which in its turn makes the update, removal, and addition of views easily achievable. The final system will have four different views: Person View (table), Task View (table), Tree view, and Gantt view.

\subsubsection{Units Description}

\begin{itemize}
\item\usefont{T1}{pcr}{m}{sl} View \\
\usefont{T1}{tnr}{m}{n} This class serves as the entry point (communication) for the View Subsystem. It keeps track of all active views and provides functions to register event handlers. Therefore, this class is responsible for sending notifications to the appropriate views. The implementation of this class should provide a function to activate the complete User Interface (\usefont{T1}{pcr}{m}{sl} initUI()\usefont{T1}{tnr}{m}{n}).
\item \usefont{T1}{pcr}{m}{sl} TableMod \\
\usefont{T1}{tnr}{m}{n} This class should be an extension of the Swing's \usefont{T1}{pcr}{m}{sl} AbstractTableModel\usefont{T1}{tnr}{m}{n}. It is an specific element needed for the chosen implementation of tables in Java. It temporarily stores the table data. It provides methods to access and modify said data based on column/row location. In this class the data type of each column is defined.
\item \usefont{T1}{pcr}{m}{sl} Table \\
\usefont{T1}{tnr}{m}{n} This class is an implementation of Swing's JTable and it collaborates with \usefont{T1}{pcr}{m}{sl} TableMod \usefont{T1}{tnr}{m}{n} (\usefont{T1}{pcr}{m}{sl}Table \usefont{T1}{tnr}{m}{n} contains an instance of the latter). While \usefont{T1}{pcr}{m}{sl} TableMod \usefont{T1}{tnr}{m}{n} provides an abstract "representation" of the data, the \usefont{T1}{pcr}{m}{sl} Table \usefont{T1}{tnr}{m}{n} class contains the specifics for its visual representation. Additionally, this class provides the possibility of registering an event handler for user modification of the data. 
\item \usefont{T1}{pcr}{m}{sl} PersonView \\
\usefont{T1}{tnr}{m}{n} To satisfy the requirements for the system's UI, the \usefont{T1}{pcr}{m}{sl} PersonView \usefont{T1}{tnr}{m}{n} class inherits from  \usefont{T1}{pcr}{m}{sl} Table. \usefont{T1}{tnr}{m}{n} This class contains the particular look (column names, etc.) and behavior of the table representation of all Person objects loaded in the  \usefont{T1}{pcr}{m}{sl} Model\usefont{T1}{tnr}{m}{n}.
\item  \usefont{T1}{pcr}{m}{sl} TableView \\
\usefont{T1}{tnr}{m}{n} Similarly to the \usefont{T1}{pcr}{m}{sl} PersonView\usefont{T1}{tnr}{m}{n} , this class inherits from the \usefont{T1}{pcr}{m}{sl} Table \usefont{T1}{tnr}{m}{n} class. Additionally, as specified by the requirements document, the \usefont{T1}{pcr}{m}{sl} TaskView \usefont{T1}{tnr}{m}{n} is editable. It represents, and allows the modification of, all the \usefont{T1}{pcr}{m}{sl} Tasks \usefont{T1}{tnr}{m}{n} loaded in  \usefont{T1}{pcr}{m}{sl} Model\usefont{T1}{tnr}{m}{n}.
\item \usefont{T1}{pcr}{m}{sl} GanttView \\
\usefont{T1}{tnr}{m}{n} The \usefont{T1}{pcr}{m}{sl} GanttView \usefont{T1}{tnr}{m}{n} class provides a visual representation of the Tasks as a sequence. It shows the Tasks and their location in a timeline, illustrating the dependency relationship among them. Since this is a very particular representation of the data, it was decided to make it a separate class.
\item \usefont{T1}{pcr}{m}{sl} TreeView \\
\usefont{T1}{tnr}{m}{n} The \usefont{T1}{pcr}{m}{sl} TreeView \usefont{T1}{tnr}{m}{n} class is provides the visual representation of the Tasks as a "file tree". It illustrates the parent/subtask relationships among the Tasks. Since this is a very particular representation of the data, it was also decided to make it a separate class. This view allows for limited user interaction: he/she can click on a Task to show/hide its associated subtasks. 
\end{itemize}

\newpage

\section{Dynamic Design Scenarios}

We chose two execution scenarios that clearly show the interaction between the different subsystems. When adding a new task, the system needs to use every subsystem. For example the \usefont{T1}{pcr}{m}{sl} TaskView \usefont{T1}{tnr}{m}{n} and \usefont{T1}{pcr}{m}{sl} View \usefont{T1}{tnr}{m}{n} classes, which are part of the View Subsystem; the class \usefont{T1}{pcr}{m}{sl} Listener\usefont{T1}{tnr}{m}{n}, which is part of the Controller Subsystem; \usefont{T1}{pcr}{m}{sl} Model \usefont{T1}{tnr}{m}{n} and \usefont{T1}{pcr}{m}{sl} Task \usefont{T1}{tnr}{m}{n} classes, which are part of the Model Subsystem. Similarly when saving the tasks back to an XML file, all subsystems are involved in fulfilling the service requested.

\subsubsection{Adding a new (empty) task}

\begin{figure}[htb]
\includegraphics[scale=0.7]{Adding_a_new_task}
\end{figure}

\newpage

\subsubsection{Saving a task file (XML)}

\begin{figure}[htb]
\includegraphics[scale=0.7]{Saving_a_task_file}
\end{figure}

\end{document}
